前幾天已經整理好「AI 避雷探針」的分析項目，也在 Day 11 實際測試 Gemini 分析 Google Maps 評論。
目前 Gemini 已經可以根據評論整理出不同的分析結果。
但如果之後要把這些結果放進網站，還有一個問題：

網站要怎麼讀取 Gemini 的回答？

如果 Gemini 每次都用一般文字回答，可能會有不同的順序、格式或寫法。
對人來說可能沒有什麼問題，但對程式來說，就比較難直接找到「整體評價」、「價格」或「等待時間」這些資料。
因此今天要把之前 Day 4 認識的 JSON 實際加入專案。

為什麼要使用 JSON？

Day 4 已經介紹過 JSON 是一種資料格式。
今天則是把它真正用在 Gemini 的輸出上。
原本 Gemini 可能會回答：
整體評價不錯，但部分評論提到等待時間較長。
餐點評價大多正面，環境也受到好評。
這些內容人可以直接閱讀，但網站如果要使用，就需要知道：
哪一段是整體評價？哪一段是餐點？哪一段是環境？
所以希望使用固定的欄位輸出。
例如：
{
"overall": "整體評價不錯",
"risk_points": [
"等待時間較長"
],
"food_service": "餐點評價正面",
"environment": "環境明亮乾淨",
"price": "無相關資訊",
"waiting_time": "部分評論提到等待時間較長",
"suspicious_review": "無明顯異常特徵",
"review_reference": "評論包含具體的用餐體驗",
"review_influence": "無相關資訊"
}
這樣每個欄位都有固定的名稱，之後 JavaScript 就可以直接取得資料。

今天怎麼測試？

今天不是重新設計一套分析方式，而是把 Day 11 已經整理好的 Prompt 加上 JSON 輸出規則。
主要增加幾個要求：
只能輸出 JSON
欄位名稱固定
沒有相關資訊時顯示「無相關資訊」
沒有雷點時使用空陣列
不自行增加或刪除欄位
不要在 JSON 前後加入其他說明文字
然後再使用 Day 11 測試過的 Google Maps 評論進行測試。

實際測試結果

這次測試後，可以看到 Gemini 已經能按照指定的欄位輸出分析結果。

例如：
overall 可以存放整體評價。
risk_points 可以存放可能的雷點，而且如果有多個雷點，可以使用陣列整理。
food_service、environment、price 和 waiting_time 則可以分別存放不同類型的分析結果。
另外，評論異常特徵和可能影響評論的因素也有各自的欄位。
這樣就能避免所有內容混在同一段文字裡。

JSON 對網站有什麼幫助？

現在整個資料流程可以更清楚地表示成：
Google Maps 評論
↓
Gemini 分析
↓
JSON
↓
JavaScript 讀取資料
↓
顯示避雷報告
例如網站之後可以讓 JavaScript 取得：
data.overall
data.risk_points
data.price
data.waiting_time

再把這些資料放到網頁對應的位置。
因此 JSON 在這裡就像是：Gemini 和網站之間的共同資料格式。
這次測試遇到的問題
實際測試後也發現，讓 Gemini 輸出 JSON 並不是只要說「請輸出 JSON」就一定完全符合需求。
有時候 AI 可能：
多輸出一些說明文字
改變欄位名稱
忘記某個欄位
把原本應該是陣列的資料變成文字
所以 Prompt 裡除了要求 JSON，也需要把欄位名稱、資料格式和缺少資料時的處理方式寫清楚。
這也是今天測試後發現的一個問題。

今天的學習

今天把 Day 4 學到的 JSON 真正應用到專案中。
我發現：
讓 AI 分析出答案，只是第一步。
如果要讓網站真正使用 AI 的結果，還需要讓 AI 用程式可以讀取的方式輸出。
因此目前的流程已經從：
評論 → Gemini → 文字
慢慢變成：
評論 → Gemini → JSON → 網站
之後製作網站實作時會繼續測試 JSON 的穩定性，確認不同評論輸入後，Gemini 是否都能維持相同的資料格式。